【レポート】AWSでオンプレミスのバックアップ戦略を近代化 #STG204 #reinvent

こんにちは、岩城です。

お客様と会話していると、これまでオンプレミスでバックアップしていたものを、AWS上でバックアップしたいと相談されることが多くなってきたと感じます。

改めてAWS上でオンプレミスのバックアップ方法を学びたいと思い、セッションを聴講しましたのでレポートします。

セッション概要

• タイトル
  • Modernize your on-premises backup strategy with AWS
• スピーカー
  • Peter Imming
• トピック
  • Storage
• セッションレベル
  • Intermediate - 200

本セッションのゴール

• AWSを利用してオンプレミスのバックアップを行う場合、どのように近代化できるか
  • オンプレで使用している既存バックアップアプリケーションを最小限に変更し
  • データを直接クラウドに移行する方法や
  • ゲートウェイデバイスを使ってオンプレミスのバックアップデータを直接クラウドストレージに移行する方法や
  • 様々なバックアップ戦略やオプションを紹介する
• AWS Backupを利用したAWSサービス全体のバックアップを一元化する方法にも少し触れる
  • EC2、EBS、EFS、RDS、Aurota、DynamoDBを利用しているならば、AWS Backupを利用してのバックアップの取得および保護することが可能
  • AWS Backupを利用すれば以下のようなことが可能
  • 自動化されたバックアップスケジューリング
  • バックアップの暗号化
  • アクセスポリシーによるバックアップデータへのアクセス制御
  • バックアップの世代管理

オンプレミスバックアップの5つの課題

• バックアップ対象のデータが大量になる
• バックアップデータがどんどん膨らむ
• 脆弱
  • 耐久性があるか、利用可能か、リージョンを越えたサイト間で復旧可能かを考慮する
• コスト高
  • 現在のバックアップストレージは高額になりすぎている
  • バックアップストレージの成長に合わせてバックアップアプライアンスを増やす必要がある
  • これは、バックアップアプライアンスの物理的な数を増やし、高いレベルの可用性と耐久性を求めるなら、別のリージョンにもバックアップし、レプリケートを考慮するということ
• 煩雑
  • バックアップアプライアンスを調達、セットアップ、保守、アップグレード、パッチを当てたり
  • 耐久年数を迎えれば、リプレースしたりとライフサイクルを回していかなければならない

オンプレミスバックアップ VS AWSストレージ

• 従来のバックアップアプライアンスを使用している場合
  • 法務チームや他部署からの依頼により、より多くのデータをバックアップし、長期間の保持が必要だったり
  • 規制された顧客であれば、政府の規制を満たすようにバックアップインフラを設定する必要がある
  • 現在のバックアップアプライアンスは、データの耐久性がイレブンナイン(0.99999999999%)以下であることを求められる
  • 要求する耐久性、可用性、回復力を単体のバックアップアプライアンスで満たせない場合、どれだけアプライアンスを増やす必要があるか
  • これらのアプライアンスを維持し、健全な状態に保ち、更新し、パッチを当て、レプリケーションするために、日々のメンテナンス時間を費やす
• AWSを利用すれば
  • バックアップアライアンスの調達、耐久性、可用性、保守、リプレースなどの課題はなくなる
  • アプライアンスのように固定コストを前払いすることなく、使用した分だけ支払うことができる
  • 調達したり、利用可能になるまで何週間も待つ必要がなく、基本的にはほぼ無限にスケールすることができる
  • メンテナンス、アップグレード、パッチ適用、コントローラやディスクのアップグレードのライフサイクル管理は全てAWSが行う
  • データの耐久性がイレブンナイン以下になることもない。ただし、低頻度アクセスのストレージクラスの場合は99.5%になる場合もある

バックアップ、リストア、アーカイブのAWSオプション

• オンプレミスのバックアップデータに焦点を当ててみる
  • 物理的なテープライブラリに保存されているデータ
  • 重複排除ストレージ・アプライアンスに保存されているデータ
  • バックアップデバイスとして利用している既存のストレージアレイに保存されているデータ
• これらのデータをリフトするためにAWSはいくつかのオプションを用意している
  • Amazon S3 and Glacier
  • Amazon EFS
  • Amazon FSx for Windows File Server

S3は業界をリードするスケーラビリティ、可用性、安全性、性能を提供する

• オブジェクト数が何兆個にもなり、保存データがエクサバイトに増えて続けていることが分かる
• 1秒あたりのリクエスト（バックアップやリストア）は、1リージョンで1秒あたり60テラバイト以上処理している
• Glacier、 Glacier Deep Archiveを含みS3はほとんどの種類のデータに対応しており、長期なバックアップデータの保存に適している
• S3は世界にまたがるストレージインフラであり、25のリージョンで稼働している
• さらに、1リージョンにつき3つのAZを持つ
• 世界中で利用可能であり、今後もリージョンを増やしながら成長する

S3の機能

• S3の機能をさまざまなカテゴリに分類できる
• 複雑さの軽減
  • 基本的にほぼ無限にスケールする
  • 物理的なテープは不要
  • バックアップデータをGlacier Deep Archiveに送る時にトラックに積んで配送する必要がない
  • 複雑さを感じさせないデータの可用性の向上
• コンプライアンスの向上
  • バックアップの長期保存やリーガルホールドも可能
• 従量制の柔軟なコスト
  • バックアップの有効期限が切れ、バックアップのサイズを小さくする必要がでてきたり、保存の必要性が変わっても、その分のコストを支払う必要はない
  • これはオンプレミスのバックアップアプライアンスにはない特徴

バックアップストレージのコスト比較

• オンプレミスのバックアップストレージの場合、以下のコストが発生する
  • データセンターのスペース、電力、冷却
  • ネットワーク
  • ハードウェア、ソフトウェアのメンテナンス
  • ライフサイクルの管理、複数台で構成していればその分嵩む
• AWSへ移行するとこれらのコストは本質的に削除される
• 意識するのは以下 　- データ転送量 　- S3へのリクエストやデータ取り出し 　 　- 特にGlacierやGlacier Deep Archiveへのリクエストは注意 　- オブジェクトの検索
• AWSでバックアップする場合のコストを試算するためにTCOカリキュレーター提供している
  • https://aws.amazon.com/tco-calculator/
• 2006年のGAから2019年までに1GBあたりの料金を80%下げている
• ストレージクラスも追加してきた
  • S3 Stadard、Glacier、Intelligent Tiering、Glacier Deep Archiveなど

オンプレミスのバックアップストレージの管理

• オンプレミスのバックアップストレージでもS3のような可用性を得る場合
• プライマリのバックアップアプライアンスににデータを書き込み、セカンダリにレプリケーションしたり
• 読み込みが増加するに従い、プライマリの容量を追加することになる
• 当然レプリケーション先も増やす必要があり、管理設定、調達など問題は深刻化する

バックアップデータのS3データ保護機能

• 複数AZにオブジェクトをコピーするだけじゃなく、S3レプリケーションを使って別リージョンへレプリケート可能
• バージョン機能を有効にしておけば、誤って削除しても過去バージョンから戻せる
• オブジェクトロックを使ってバックアップデータのガバナンスやコンプライアンスのためにオブジェクトを保護可能
• 法的な目的のためにリーガルホールドを使って保持可能

Storage Gateway

• オンプレミスのバックアップをAWSに取得する方法としてStorage Gatewayを紹介する
• Storage Gatewayは複数の種類がある
  • File Gateway
  • Volume Gateway
  • Tape Gateway
• File GatewayはNFSやSMBベース
• Volume Gatewayはブロックストレージ用
• Tape Gatewayはテープライブラリ用

Tape Gateway

• 物理的なテープライブラリの代わりに、Tape Gatewayを使用してS3にアーカイブすることができる

• Tape Gatewayを使用して70%のコストを削減したお客様がいる
• コスト削減の内訳は以下
  • テープライブラリの電源、冷却
  • テープ、テープライブラリの購入
  • ソフトウェアのメンテナンス
  • トラックに積んでの移送
  • これらに関わる人的リソース

直接S3にバックアップする

• バックアップソフトウェアに依存するが、Tape Gatewayを使わずとも直接S3にバックアップできるケースがある
• バックアップソフトウェアのベンダーに相談してみること

Amazon EFS

• フルマネージドなNFS対応のバックアップ
• Oracle RMANやSAPバックエンドのバックアップなどNFS性互換性のあるストレージ
• データベースや、アプリケーションがNFSストレージに直接書き込める

Amazon FSx For Windows File Server

• Microsoft SQL Server、SharePoint、ExchangeなどのWindowsアプリケーションのバックアップ先
• フルマネージドサービス、大規模なファイルシステムでネイティブにバックアップを書き込むことができる
• 物理的なNASに保存しているよりもコストが最適化されている
• Microsoft SQL ServerのVDIストリームやVSSスナップショット、ファイルシステムのバックアップに最適

どのように近代化するか？決断のポイント

• 目標に対して、その目標を達成するための質問、チェックリスト
• バックアップ戦略を近代化したいが、既存のバックアップアプリケーションを使いたい
  • 既存のバックアップソフトはS3へ直接書き込めるか、ゲートウェイデバイスが必要なのか
• オフサイトのバックアップを持っている必要がある。保存先として適切な場所はどこか
  • バックアップを2つの異なる場所に保存したいか
  • バックアップのオフサイト戦略はどのようなものか
• 高速リカバリーのためにバックアップデータをローカルに保持する必要がある
  • RPOとRTOはどのくらいか
  • 高速にリカバリーする必要があるか
  • そもそもローカルにコピーを保存してまで高速にリカバリーする必要があるか
• こうした要件に対し、AWS Storage Gatewayは、ファイルやボリュームベースの機能を提供しており、高速なリカバリーのためにローカルにバックアップを保存可能
• 信頼性が高く、耐久性があり、可用性が高い低コストのストレージが必要
  • 自分でバックアップストレージを調達、設定、パッチ適用、アップデートしたり管理し続けるか
  • AWSのサービスと現在のストレージを比較してどのようなメリットがあるか
• バックアップのコピーを不正削除から守りたい
  • バックアップの保存先にどの程度の安全性があるのか
  • 不正削除やランサムウェアからの不正な暗号化からの安全性があるのか

バックアップ戦略の近代化は複数ステップを経て行われる

• ステップ1
  • 既存バックアップソフトウェアとの互換性により、物理的なテープを排除する
• ステップ2
  • S3、EFS、FSxに直接バックアップできるバックアップアプリケーションを探す
• ステップ3
  • クラウドネイティブなアプリケーションにシフトし、DynamoDBやAuroraなどのAWSサービスをAWS Backupを使ってバックアップする

感想

オンプレミスのバックアップ戦略をAWSにシフトするにはどうすれば良いかを知ることができるセッションでした。

このセッションで触れられていませんでしたが、オンプレにあるバックアップをAWSに持っていく際は、Direct Connectを使うことを検討されることが多いかと思います。

バックアップデータは大きなサイズになりがちです。通常のサービスと同じ回線を使うとバックアップの通信により、Direct Connectの帯域を逼迫させ、サービスへ影響を与える要因にもなり得ます。

バックアップ用の回線を設けたり、同じ回線を使う場合でもサービス時間外でバックアップするなども考慮しましょう。

本エントリがどなたかのお役に立てれば幸いです。